좋아요. 아래는 주어진 조건(사용자 수/동시접속률, Docker 컨테이너, 운영 HA 2대, OS·Docker 오버헤드)로 VM 서버 스펙을 산정하는 근거와 최종 제안 스펙입니다. 숫자는 실무에서 바로 적용할 수 있게 가정 → 계산 → 라운딩(여유 포함) 순서로 정리했습니다.

1) 공통 가정(현실적인 기본값)

• 동시접속자(동접):

  • 개발: 20명 중 10명(50%)

  • 검증: 100명 중 50명(운영의 50%로 산정)

  • 운영: 200명 중 100명(50%)

• 애플리케이션 특성: Mendix/Java(Tomcat 등) Docker 컨테이너로 구동

• 자원 당 소요량(경량 트랜잭션 기준, 보수적으로 산정)

  • CPU: 1 동접 ≈ 0.04 vCPU → 100 동접 ≈ 4 vCPU

  • 메모리(Heap): 1 동접 ≈ 80 MB → 100 동접 ≈ 8 GB

  • 비힙/네이티브/GC 버퍼: Heap의 25% (≈ 메모리 오버헤드)

• 여유율(Headroom): 급증/GC/배치 대비 +30%

• 오버헤드

  • Docker + Compose: VM 자원 대비 5~10%

  • VM OS: VM 자원 대비 10~15%

• HA 정책(운영): N-1 기준(노드 1대 장애 시 나머지 1대가 전부 처리 가능하도록 각 노드 산정)

실측을 진행하면 값 미세조정 가능. 초기 구축은 보수적으로 잡고, 모니터링 지표로 추후 다운사이징/업사이징 권장.

2) 단계별 계산 근거

2.1 CPU 산정(컨테이너 기준)

• 개발(동접 10): 0.04×10=0.4 vCPU → +30% = 0.52 vCPU

• 검증(동접 50): 0.04×50=2 vCPU → +30% = 2.6 vCPU

• 운영(동접 100): 0.04×100=4 vCPU → +30% = 5.2 vCPU

운영은 N-1이므로 각 노드가 100 동접을 단독 처리하도록 컨테이너 5.2 vCPU 이상 필요.

2.2 메모리 산정(컨테이너 기준)

• 개발(동접 10): Heap 0.8 GB + 비힙(25%) 0.2 GB = 1.0 GB → +30% = 1.3 GB

• 검증(동접 50): Heap 4 GB + 1 GB = 5 GB → +30% = 6.5 GB

• 운영(동접 100): Heap 8 GB + 2 GB = 10 GB → +30% = 13 GB

컨테이너 메모리 제한은 Xmx(Heap) 뿐 아니라 비힙/GC까지 포함하도록 Xmx 대비 1.3~1.5배 권장.

2.3 VM 오버헤드 반영 & 실배치 라운딩

• 위 컨테이너 자원 외에 OS 1015% + Docker 510% 오버헤드 고려 → VM 자원은 컨테이너 요구 대비 약 +20~25% 여유 권장

• 최소 운영 편의성(빌드/로그/툴)도 고려해 최소 스펙 하한 설정

3) 최종 권장 스펙(요약 표)

왜 이렇게?

• 운영 컨테이너 요구(≈5.2 vCPU/13GB) + VM 오버헤드 약 20~25% + 운영툴/에이전트/버퍼 고려 → VM 8 vCPU / 32 GB가 안정적

• 개발/검증은 동접·테스트 패턴 고려해 운영 대비 단계적 축소

4) 스토리지 상세 산정(분리 권장)

성능 권장

• 운영: SSD/NVMe, IOPS ≥ 3,000, 랜덤 R/W 혼합, 순차 처리 시 ≥100 MB/s

• 파일시스템: ext4 또는 xfs, noatime, 로그/데이터 볼륨 분리

• 백업: 일 스냅샷(7일), 주간(4주), 월간(3~6개월) + 오브젝트 스토리지 원격 보관

5) 컨테이너 리소스 제한 예시(Docker Compose)

yaml
Copy code
services:
  app:
    image: your-registry/your-mendix-java:tag
    deploy:
      resources:
        limits:
          cpus: "6.0"          # 운영 노드에서 컨테이너 상한(요구 5.2 vCPU + 여유)
          memory: "20g"        # Xmx 12~14g 기준 1.4~1.6배
        reservations:
          cpus: "4.0"
          memory: "14g"
    environment:
      - JAVA_TOOL_OPTIONS=-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UseStringDeduplication
      - JAVA_OPTS=-Xms12g -Xmx12g
    volumes:
      - /var/lib/yourapp/data:/app/data
      - /var/log/yourapp:/app/logs
    logging:
      driver: "json-file"
      options:
        max-size: "200m"
        max-file: "10"

운영 VM이 8 vCPU/32GB이므로, 컨테이너 상한을 CPU 6 vCPU / 메모리 20GB 수준으로 컷팅하면 OS+Docker 오버헤드(≈20~25%)와 모니터링/사이드카 여유를 확보.

6) OS/플랫폼 튜닝 체크리스트

• 커널/OS

  • 스와핑 최소화: vm.swappiness=1

  • 파일 디스크립터 상향: fs.file-max, ulimit nofile ≥ 65535

  • 시계 동기화: chrony

• Docker/저장소

  • 스토리지 드라이버: overlay2

  • 로그 로테이션: json-file + size/file 제한

  • 빌드 캐시 주기적 정리: docker system prune (운영은 보수적으로)

• JVM

  • Java 11+ 컨테이너 인식(기본 활성)

  • G1GC, MaxGCPauseMillis=200~500 조정

  • -Xms = -Xmx(운영), Metaspace 여유

• 모니터링/알림

  • CPU 사용률(1·5·15m), GC pause, Heap/OldGen, 컨테이너 RSS

  • 디스크 사용률/IOPS/latency, 네트워크 오류

  • SLO: p95/p99 응답 시간, 에러율, QPS

7) 용량 검증(성능테스트 권장 시나리오)

1. 부하도구(k6/JMeter)로 100% 피크 + 30% 버스트 30~60분

2. 실패율 < 1%, p95 응답시간 목표 내(예: 300~500ms)

3. N-1 테스트: 운영 노드 1대 중지(Drain) → 남은 1대 지표 확인

4. 결과 기반으로 컨테이너 상한/VM 스펙 재산정(다운사이징 가능)

결론 요약

• 운영(HA): 8 vCPU / 32GB / 600GB(노드당), 2노드 → N-1 안정성 확보

• 검증: 8 vCPU / 24GB / 500GB → 운영 유사 테스트에 충분

• 개발: 4 vCPU / 16GB / 300GB → 동접·툴 사용 고려한 실용 하한

• 근거: 동접당 자원 모델(0.04 vCPU, 80MB Heap) + 30% 여유 + OS/Docker 20~25% 오버헤드 + 운영 툴/로그/스토리지 분리

필요하시면 위 스펙을 표준 문서(PDF/PPT) 형태로 바로 정리해서 드릴게요.